01-고가용성테스트

고가용성 테스트

목표

완성된 고가용성 웹 서비스가 실제로 장애에 강한지 테스트해봅니다.

완성된 아키텍처 확인

전체 구조

사용자
  ↓
ALB (2개 가용영역)
  ↓
Web 서버 (Auto Scaling, 최소 2대)
  ↓
WAS 서버 (Private, 기존 1대)
  ↓
RDS (Multi-AZ, Primary + Standby)

구성 요소 체크리스트

ALB가 2개 가용영역에 배치됨
Auto Scaling Group에 Web 서버 2대 이상 실행 중
Target Group에서 모든 서버가 healthy 상태
RDS가 Multi-AZ로 설정됨
웹 애플리케이션이 정상 동작함

테스트 1: 웹 서버 장애 시뮬레이션

Web 서버 1대 강제 종료

EC2 콘솔 → 인스턴스
Auto Scaling으로 생성된 Web 서버 중 1대 선택
인스턴스 상태 → 인스턴스 종료

복구 과정 확인

1-2분 후:

Target Group에서 종료된 서버가 unhealthy로 변경
ALB가 자동으로 해당 서버로 트래픽 차단

3-5분 후:

Auto Scaling이 종료된 서버를 감지
새로운 서버 자동 생성 시작

8-10분 후:

새 서버가 완전히 준비됨
Target Group에 자동 등록되어 healthy 상태

사용자 영향 확인

웹 사이트 접속 테스트:

http://ALB-DNS-Name/webapp/

결과:

서버 1대 종료되어도 웹사이트 계속 동작
약간의 응답 지연은 있을 수 있지만 서비스 중단 없음
새 사용자 등록/조회 기능 정상 동작

테스트 2: 가용영역 장애 시뮬레이션

한 가용영역의 모든 Web 서버 종료

Auto Scaling 그룹 → webapp-web-asg
인스턴스 탭에서 한 가용영역의 모든 서버 확인
해당 가용영역의 서버들을 모두 종료

예시:

ap-northeast-2a의 서버 1대 종료
ap-northeast-2c의 서버는 유지

복구 과정 확인

즉시:

남은 가용영역의 서버들이 모든 트래픽 처리
웹사이트 계속 동작

5-10분 후:

Auto Scaling이 종료된 서버들 감지
새 서버들을 다른 가용영역에 생성

사용자 영향 확인

결과:

한 가용영역 전체 장애에도 서비스 지속
일시적 성능 저하는 있지만 완전 중단은 없음

테스트 3: 데이터베이스 장애복구 테스트

RDS 강제 장애복구

RDS 콘솔 → 데이터베이스 인스턴스 선택
작업 → 재부팅
장애 조치를 통해 재부팅 체크
재부팅 클릭

복구 과정 확인

재부팅 시작:

Primary DB 중지됨
웹 애플리케이션에서 DB 연결 오류 발생

1-2분 후:

Standby DB가 자동으로 Primary로 승격
웹 애플리케이션 DB 연결 복구

5분 후:

새로운 Standby DB 생성 완료
Multi-AZ 구성 복원

사용자 영향 확인

결과:

1-2분간 DB 관련 기능 중단
이후 완전 정상 동작 복구
데이터 손실 없음

테스트 4: 부하 테스트

동시 사용자 시뮬레이션

여러 브라우저 창에서 동시에 웹사이트 접속:

# 간단한 부하 테스트 (Web 서버에서 실행)
for i in {1..50}; do
  curl -s http://ALB-DNS-Name/webapp/ > /dev/null &
done
wait

Auto Scaling 동작 확인

CPU 사용률 모니터링:

EC2 콘솔 → 인스턴스 → 서버 선택
모니터링 탭에서 CPU 사용률 확인

스케일링 확인:

CPU 사용률이 70% 이상 지속되면
5-10분 후 새 서버 추가 생성

결과 확인

기대 결과:

부하 증가 시 자동으로 서버 추가
부하 감소 시 자동으로 서버 제거
사용자는 일관된 성능 경험

테스트 5: 전체 시나리오 테스트

복합 장애 시뮬레이션

Web 서버 1대 종료
동시에 높은 트래픽 발생
DB 장애복구 실행

전체 시스템 복원력 확인

결과:

여러 장애가 동시 발생해도 서비스 지속
각 구성 요소가 독립적으로 복구
사용자 경험 최소 영향

성능 벤치마크

장애 전후 성능 비교

정상 상태:

응답 시간: 약 200-500ms
동시 처리: 여러 사용자 문제없음

장애 발생 시:

일시적 지연: 1-3초
복구 후: 정상 성능 회복

개선된 안정성:

서버 장애: 영향 없음
가용영역 장애: 영향 최소
DB 장애: 1-2분 복구

완료 체크리스트

고가용성 테스트 완료

Web 서버 1대 종료해도 서비스 지속
Auto Scaling이 장애 서버 자동 교체
가용영역 장애 시뮬레이션 통과
DB 장애복구 테스트 통과
부하 증가 시 자동 확장 동작
복합 장애 상황에서도 서비스 지속

성능 확인

ALB를 통한 부하 분산 정상 동작
여러 서버에서 일관된 응답
데이터베이스 연결 안정성 확인
사용자 경험 품질 유지

고가용성 달성 요약

Before (Week3)

장애 발생 시:
- 서버 1대 고장 → 전체 서비스 중단
- 복구: 수동 개입 필요
- 사용자: 서비스 이용 불가

After (Week3.5)

장애 발생 시:
- 서버 1대 고장 → 다른 서버가 처리
- 복구: 자동으로 새 서버 생성
- 사용자: 서비스 지속 이용 가능

개선 지표

항목	이전	이후
서버 다운타임	100%	0%
복구 시간	수동 (시간 단위)	자동 (분 단위)
사용자 영향	완전 중단	거의 없음
확장성	수동	자동

운영 가이드

일상 모니터링 항목

Auto Scaling Group 상태
Target Group의 healthy 인스턴스 수
RDS Multi-AZ 상태
CloudWatch 알람 상태

장애 대응 절차

알람 수신 시 확인 사항
각 구성 요소별 복구 방법
에스컬레이션 절차

고가용성 테스트 완료

축하합니다! Netflix나 Amazon처럼 절대 죽지 않는 웹 서비스를 구축했습니다.

다음 단계: Week 4에서 모니터링과 비용 최적화를 배워보겠습니다.